In defense of boring technology

There is a moment in every project where someone proposes the interesting choice. The new runtime, the clever database, the framework whose conference talks are genuinely electric. I have been that someone. This essay is the apology.

Dan McKinley's framing still holds: every team gets a small number of innovation tokens, and the winning move is to spend them where your product is actually different. Spend them on your scheduling engine, your editor, your sync layer — the thing customers pay you for. Do not spend them on the queue.

What boring buys

Boring technology is not old technology. It is technology whose failure modes are known. When the boring database misbehaves at 2 a.m., the error message has a decade of answers attached to it, three of them written by people who fixed exactly your problem. When the exciting one misbehaves, you are the documentation now.

• Known failure modes beat theoretical performance.
• Hiring is easier for tools people already know.
• Operational muscle memory transfers between projects.
• The ecosystem has already built what you were about to build.

The asymmetry nobody prices in

The exciting choice charges rent forever. Every upgrade, every incident, every new hire's onboarding pays a little tax to that decision. The boring choice charges almost nothing, which is why it never gets credit — its victories are the outages that did not happen and the weekends nobody lost.

Meanwhile the excitement itself depreciates. The thrilling framework of three years ago is just a framework now, minus the community that moved on. Postgres, meanwhile, is still there, still mocked as a default, still quietly running most of the internet that works.

Choose boring where you are the same as everyone else, so you can afford to be interesting where you are not.

The discipline is not conservatism. It is aim. Boring infrastructure is how you buy the slack to be genuinely radical in the one place radical pays.